Make CI more reliable #261
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This refactors the
watch(),onChange()andAttachmentTestimplementations to improve the reliability of the CI.First, both
watch()andonChange()were implemented as achannelFlowthis is a somewhat problematic builder, since (quoting the docs):This means that when we call
send(), it doesn't necessarily wait for the downstream consumer to process that event, leading to the query potentially running more often than necessary (the behavior we want is to internally buffer upstream changes while a downstream consumer is busy, and then once it handled the previous event we'd re-run the query if there were any changes in the meantime).I've refactored the implementation to use a regular flow, ensuring that we won't start running a second query until results of the first one are handled. I've also simplified the implementation to reuse more logic between
watchandonChange.Additionally, this updates some attachment tests:
testSkipFailedDownloadtest asserts a visible transition fromQUEUED_DOWNLOADtoARCHIVED. Depending on how often theSELECT * FROM attachmentsflow emits items though, it's possible that theQUEUED_DOWNLOADstate is not observable. This updates the test to reflect that.SELECT * FROM atttachmentsflow are decoupled and asynchronous, it's possible that a write to the todos table schedules a query that, at the time it runs, sees a different write. This has been causing a few failures as well, adistinctUntilChanged()deflakes those tests.waitFortiming out, so this adds more logs around that and replaces thewaitForcalls in attachment tests.